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Abstract 


As the deployment of third and fourth generation cellular networks 
progresses, a large number of cellular hosts are being connected to 
the Internet.  Standardization organizations have made the Internet 
Protocol version 6 (IPv6) mandatory in their specifications. 
However, the concept of IPv6 covers many aspects and numerous 
Specifications. In addition, the characteristics of cellular links 
in terms of bandwidth, cost, and delay put special requirements on 
how IPv6 is used. This document considers IPv6 for cellular hosts 
that attach to the General Packet Radio Service (GPRS), Universal 
Mobile Telecommunications System (UMTS), or Evolved Packet System 
(EPS) networks (hereafter collectively referred to as Third 
Generation Partnership Project (3GPP) networks). This document also 
lists specific IPv6 functionalities that need to be implemented in 
addition to what is already prescribed in the IPv6 Node Requirements 
document (RFC 6434). It also discusses some issues related to the 
use of these components when operating in these networks. This 
document obsoletes RFC 3316. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7066. 
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1. Introduction 


Technologies such as GPRS (General Packet Radio Service), UMTS 
(Universal Mobile Telecommunications System), Evolved Packet System 
(EPS), CDMA2000 (Code Division Multiple Access 2000), and eHRPD 
(Enhanced High Rate Packet Data) are making it possible for cellular 


hosts to have an always-on connection to the Internet.  IPv6 
[RFC2460] has become essential to such networks as the number of 
cellular hosts is increasing rapidly.  Standardization organizations 


working with cellular technologies have recognized this and made IPv6 
mandatory in their specifications. 


Support for IPv6 and the introduction of UMTS started with 3GPP 
Release-99 networks and hosts. For a detailed description of IPv6 in 
3GPP networks, including the Evolved Packet System, see [RFC6459]. 


1.1. Scope of This Document 


For the purpose of this document, a cellular interface is considered 
to be the interface to a cellular access network based on the 
following standards: 3GPP GPRS and UMTS Release-99 and Release-4 to 
Release-11; EPS Release-8 to Release-11; and future UMTS or EPS 
releases. A cellular host is considered to be a host with such a 
cellular interface. 


This document complements the IPv6 Node Requirements [RFC6434] in 
places where clarifications are needed with discussion on the use of 
these selected IPv6 specifications when operating over a cellular 
interface. Such a specification is necessary in order to enable the 
optimal use of IPv6 in a cellular network environment. The 
description is made from the point of view of a cellular host. 
Complementary access technologies may be supported by the cellular 
host, but those are not discussed in detail. Important 
considerations are given in order to eliminate unnecessary user 
confusion over configuration options, ensure interoperability, and 
provide an easy reference for those who are implementing IPv6 in a 
cellular host. It is necessary to ensure that cellular hosts are 
good citizens of the Internet. 


This document is informational in its nature, and it is not intended 
to replace, update, or contradict any IPv6 standards documents or the 
IPv6 Node Requirements [RFC6434]. 


This document is primarily targeted to the implementers of cellular 
hosts that will be used with the cellular networks listed in this 
document. This document provides guidance on which IPv6-related 
Specifications are to be implemented in such cellular hosts. Parts 
of this document may also apply to other cellular link types, but 
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this document does not provide any detailed analysis on other link 
types. This document should not be used as a definitive list of IPv6 
functionalities for cellular links other than those listed above. 
Future changes in 3GPP networks that impact host implementations may 
result in updates to this document. 


There are different ways to implement cellular hosts: 


o The host can be a "closed" device with optimized built-in 
applications, with no possibility to add or download applications 
that can have IP communications. An example of such a host is a 
very simple form of a mobile phone. 


o The host can be an open device, e.g., a "smart phone" where it is 
possible to download applications to expand the functionality of 
the device. 


o The cellular radio modem part can be separated from the host IP 
Stack with an interface. One example of such a host is a laptop 
computer that uses a USB cellular modem for cellular access. 


If a cellular host has additional IP-capable interfaces (such as 
Ethernet, WLAN, Bluetooth, etc.), then there may be additional 
requirements for the device, beyond what is discussed in this 
document. Additionally, this document does not make any 
recommendations on the functionality required on laptop computers 
having a cellular interface such as an embedded modem or a USB modem 
Stick, other than recommending link-specific behavior on the cellular 
link. 


This document discusses IPv6 functionality as of the time when this 
document was written. Ongoing work on IPv6 may affect what is 
required of future hosts. 


Transition mechanisms used by cellular hosts are not in the scope of 
this document and are left for further study. The primary transition 
mechanism supported by 3GPP is dual-stack [RFC4213].  Dual-stack- 
capable bearer support has been added to GPRS starting from 3GPP 
Release-9 and to EPS starting from Release-8 [RFC6459], whereas the 
earlier 3GPP releases required multiple single IP version bearers to 
support dual-stack. 
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1.2. Abbreviations 


2G 


3G 


4G 


3GPP 


EPS 


GGSN 


GPRS 
LTE 
MT 
MTU 
PDN 
PDP 


PGW 


SGW 


TE 


UMTS 


WLAN 


Korhonen, 


Second Generation Mobile Telecommunications, such as Global 
System for Mobile Communications (GSM) and GPRS technologies. 


Third Generation Mobile Telecommunications, such as UMTS 
technology. 


Fourth Generation Mobile Telecommunications, such as LTE 
technology. 


Third Generation Partnership Project. Throughout the document, 
the term "3GPP networks" refers to architectures standardized 
by 3GPP, in Second, Third, and Fourth Generation releases: 99, 
4, and 5, as well as future releases. 


Evolved Packet System. 


Gateway GPRS Support Node (a default router for 3GPP IPv6 
cellular hosts in GPRS). 


General Packet Radio Service. 

Long Term Evolution. 

Mobile Terminal, for example, a mobile phone handset. 
Maximum Transmission Unit. 

Packet Data Network. 

Packet Data Protocol. 


Packet Data Network Gateway (the default router for 3GPP IPv6 
cellular hosts in EPS). 


Serving Gateway (the user plane equivalent of a Serving GPRS 
Support Node (SGSN) in EPS (and the default router for 3GPP 
IPv6 cellular hosts when using Proxy Mobile IPv6 (PMIPv6))). 


Terminal Equipment, for example, a laptop attached through a 
3GPP handset. 


Universal Mobile Telecommunications System. 


Wireless Local Area Network. 
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1.3. Cellular Host IPv6 Features 


This document lists IPv6 features for cellular hosts; these features 
are split into three groups and are discussed below. 


Basic IP 


In this group, the basic IPv6 features essential for cellular 
hosts are listed and described. 


IP Security 
In this group, the parts related to IP Security are described. 
Mobility 
In this group, IP-layer mobility issues are described. 
2. Basic IP 


For most parts, refer to the IPv6 Node Requirements document 
[RFC6434]. 


2.1. Internet Protocol Version 6 
The Internet Protocol version 6 (IPv6) is specified in [RFC2460]. 
This specification is a mandatory part of IPv6. A cellular host must 
conform to the generic IPv6 host requirements [RFC6434], unless 
specifically pointed out otherwise in this document. 


2.2. Neighbor Discovery in 3GPP Networks 


A cellular host must support Neighbor Solicitation and Neighbor 


Advertisement messages [RFC4861]. Some further notes on how Neighbor 
Discovery is applied in the particular type of an interface can be 
useful. 


In 3GPP networks, some Neighbor Discovery messages can be unnecessary 
in certain cases. GPRS, UMTS, and EPS links resemble a point-to- 
point link; hence, the cellular host's only neighbor on the cellular 
link is the default router that is already known through Router 
Discovery. The cellular host always solicits for routers when the 
cellular interface is brought up (as described in [RFC4861], 

Section 6.3.7). 


There are no link-layer addresses on the 3GPP cellular link 
technology. Therefore, address resolution and next-hop determination 
are not needed. If the cellular host still attempts to do address 
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resolution, e.g., for the default router, it must be understood that 
the GGSN/PGW may not even answer the address resolution Neighbor 
Solicitations. And even if it does, the Neighbor Advertisement is 
unlikely to contain the Target link-layer address option as there are 
no link-layer addresses on the 3GPP cellular link technology. 


The cellular host must support Neighbor Unreachability Detection 
(NUD) as specified in [RFC4861]. Note that the link-layer address 
considerations above also apply to NUD. The NUD-triggered Neighbor 
Advertisement is also unlikely to contain the Target link-layer 


address option as there are no link-layer addresses. The cellular 
host should also be prepared for NUD initiated by a router (i.e., 
GGSN/PGW). However, it is unlikely a router-to-host NUD would ever 


take place on GPRS, UMTS, or EPS links. See Appendix A for more 
discussion on the router-to-host NUD. 


In 3GPP networks, it is desirable to reduce any additional periodic 
signaling. Therefore, the cellular host should include a mechanism 
in upper-layer protocols to provide reachability confirmations when 
two-way IP-layer reachability can be confirmed (see [RFC4861], 
Section 7.3.1). These confirmations would allow the suppression of 
NUD-related messages in most cases. 


Host TCP implementation should provide reachability confirmation in 
the manner explained in [RFC4861], Section 7.3.1. 


The widespread use of UDP in 3GPP networks poses a problem for 
providing reachability confirmation. As UDP itself is unable to 
provide such confirmation, applications running on top of UDP should 
provide the confirmation where possible. In particular, when UDP is 
used for transporting DNS, the DNS response should be used as a basis 
for reachability confirmation. Similarly, when UDP is used to 
transport RTP [RFC3550], the RTP Control Protocol (RTCP) [RFC3550] 
feedback should be used as a basis for the reachability confirmation. 
If an RTCP packet is received with a reception report block 
indicating some packets have gone through, then packets are reaching 
the peer. If they have reached the peer, they have also reached the 
neighbor. 


When UDP is used for transporting SIP [RFC3261], responses to SIP 
requests should be used as the confirmation that packets sent to the 
peer are reaching it. When the cellular host is acting as the 
server-side SIP node, no such confirmation is generally available. 
However, a host may interpret the receipt of a SIP ACK request as 
confirmation that the previously sent response to a SIP INVITE 
request has reached the peer. 
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2.3. Stateless Address Autoconfiguration 


IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 
This specification is a mandatory part of IPv6 and also the only 
mandatory method to configure an IPv6 address in a 3GPP cellular 
host. 


A cellular host in a 3GPP network must process a Router Advertisement 
as stated in [RFC4862]. The Router Advertisement contains a maximum 
of one prefix information option with lifetimes set to infinite (both 
valid and preferred lifetimes). The advertised prefix cannot ever be 
used for on-link determination (see [RFC6459], Section 5.2), and the 
lifetime of the advertised prefix is tied to the PDP Context/PDN 
Connection lifetime. Keeping the forward compatibility in mind, 
there is no reason for the 3GPP cellular host to have 3GPP-specific 
handling of the prefix information option(s) although 3GPP 
specifications state that the Router Advertisement may contain a 
maximum of one prefix information option and the lifetimes are set to 
infinite. 


Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, 
as each assigned prefix is unique within its scope when advertised 
using 3GPP IPv6 Stateless Address Autoconfiguration. In addition, 
the default router (GGSN/PGW) will not configure any addresses on its 
interfaces based on prefixes advertised to IPv6 cellular hosts on 
those interfaces. Thus, the host is not required to perform 
Duplicate Address Detection on the cellular interface. 


Furthermore, the GGSN/PGW will provide the cellular host with an 
interface identifier that must be used for link-local address 
configuration. The link-local address configured from this interface 
identifier is guaranteed not to collide with the link-local address 
that the GGSN/PGW uses. Thus, the cellular host is not required to 
perform Duplicate Address Detection for the link-local address on the 
cellular interface. 


See Appendix A for more details on 3GPP IPv6 Stateless Address 
Autoconfiguration. 


2.4. IP Version 6 over PPP 


A cellular host in a 3GPP network that supports PPP [RFC1661] on the 
interface between the MT and the TE must support the IPv6 Control 
Protocol (IPV6CP) [RFC5072] interface identifier option. This option 
is needed to be able to connect other devices to the Internet using a 
PPP link between the cellular device (MT, e.g., a USB dongle) and 
other devices (TE, e.g., a laptop). The MT performs the PDP Context 
activation based on a request from the TE. This results in an 
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interface identifier being suggested by the MT to the TE, using the 
IPV6CP option. To avoid any duplication in link-local addresses 
between the TE and the GGSN/PGW, the MT must always reject other 
suggested interface identifiers by the TE. This results in the TE 
always using the interface identifier suggested by the GGSN/PGW for 
its link-local address. 


The rejection of interface identifiers suggested by the TE is only 
done for creation of link-local addresses, according to 3GPP 
Specifications. The use of privacy addresses [RFC4941] or similar 
technologies for unique local IPv6 unicast addresses [RFC4193] and 
global addresses is not affected by the above procedure. 


2.5. Multicast Listener Discovery (MLD) for IPv6 


Within 3GPP networks, hosts connect to their default routers 
(GGSN/PGW) via point-to-point links. Moreover, there are exactly two 
IP devices connected to the point-to-point link, and no attempt is 
made (at the link layer) to suppress the forwarding of multicast 
traffic. Consequently, sending MLD reports for link-local addresses 
in a 3GPP environment is not necessary, although sending them causes 
no harm or interoperability issues. Refer to Section 5.10 of 
[RFC6434] for MLD usage for multicast group knowledge that is not 
link-local. 


2.6. Privacy Extensions for Address Configuration in IPv6 


Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 
or other similar technologies may be supported by a cellular host. 
Privacy, in general, is important for the Internet. In 3GPP 
networks, the lifetime of an address assignment depends on many 
factors such as radio coverage, device status, and user preferences. 
As a result, the prefix the cellular host uses is also subject to 
frequent changes. 


Refer to Section 6 for a discussion of the benefits of Privacy 
Extensions in a 3GPP network. 


2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 


As of 3GPP Release-11, the Dynamic Host Configuration Protocol for 
IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address 
autoconfiguration.  IPv6 Stateless Address Autoconfiguration still 
remains the only mandatory address configuration method. However, 
DHCPv6 may be useful for other configuration needs on a cellular 
host, e.g., Stateless DHCPv6 [RFC3736] may be used to configure DNS 
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and SIP server addresses, and DHCPv6 Prefix Delegation [RFC3633] may 
be used to delegate a prefix to the cellular host for use on its 
downstream non-cellular links. 


2.8. DHCPv6 Prefix Delegation 


Starting from Release-10, DHCPv6 Prefix Delegation was added as an 
optional feature to the 3GPP system architecture [RFC3633]. The 
Prefix Delegation model defined for Release-10 requires that the /64 
IPv6 prefix assigned to the cellular host on the 3GPP link must 
aggregate with the shorter delegated IPv6 prefix. The cellular host 
should implement the Prefix Exclude Option for DHCPv6 Prefix 
Delegation [RFC6603] (see [RFC6459], Section 5.3 for further 
discussion). 


2.9. Router Preferences and More-Specific Routes 


The cellular host should implement the Default Router Preferences and 
More-Specific Routes extension to Router Advertisement messages 
[RFC4191]. These options may be useful for cellular hosts that also 
have additional interfaces on which IPv6 is used. 


2.10. Neighbor Discovery and Additional Host Configuration 


The DNS server configuration is learned from the 3GPP link-layer 
signaling. However, the cellular host should also implement the IPv6 
Router Advertisement Options for DNS Configuration [RFC6106].  DHCPv6 
is still optional for cellular hosts, and learning the DNS server 
addresses from the link-layer signaling can be cumbersome when the MT 
and the TE are separated using techniques other than the PPP 
interface. 


The cellular host should also honor the MTU option in the Router 
Advertisement (see [RFC4861], Section 4.6.4). The 3GPP system 
architecture uses extensive tunneling in its packet core network 
below the 3GPP link, and this may lead to packet fragmentation 
issues. Therefore, the GGSN/PGW may propose to the cellular host an 
MTU that takes the additional tunneling overhead into account. 


Korhonen, et al. Informational [Page 10] 


RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 


3. IP Security 


IPsec [RFC4301] is a fundamental, but not mandatory, part of IPv6. 
Refer to the IPv6 Node Requirements (Section 11 of [RFC6434]) for the 
security requirements that also apply to cellular hosts. 


3.1. Extension Header Considerations 
Support for the Routing Header Type 0 (RHO) has been deprecated 


[RFC5095]. Therefore, the cellular host should by default follow the 
RHO processing described in Section 3 of [RFC5095]. 


IPv6 packet fragmentation has known security concerns. The cellular 
host must follow the handling of overlapping fragments as described 
in [RFC5722], and the cellular host must not fragment any Neighbor 
Discovery messages as described in [RFC6980]. 


4. Mobility 


For the purposes of this document, IP mobility is not relevant. The 
movement of cellular hosts within 3GPP networks is handled by link- 
layer mechanisms in the majority of cases.  3GPP Release-8 introduced 
Dual-Stack Mobile IPv6 (DSMIPv6) for client-based mobility [RFC5555]. 
Client-based IP mobility is optional in the 3GPP architecture. 
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6. Security Considerations 


This document does not specify any new protocols or functionalities, 
and as such, it does not introduce any new security vulnerabilities. 
However, specific profiles of IPv6 functionality are proposed for 
different situations, and vulnerabilities may open or close depending 
on which functionality is included and what is not. There are also 
aspects of the cellular environment that make certain types of 
vulnerabilities more severe. The following issues are discussed: 


o The suggested limitations (Section 3.1) in the processing of 
extension headers also limits exposure to Denial-of-Service (DoS) 
attacks through cellular hosts. 


o IPv6 addressing privacy [RFC4941] or similar technology may be 
used in cellular hosts. However, it should be noted that in the 
3GPP model, the network would assign a new prefix, in most cases, 
to hosts in roaming situations; the network would also typically 
assign a new prefix when the cellular hosts activate a PDP Context 
or a PDN Connection. 3GPP devices must not use interface 
identifiers that are unique to the device, so the only difference 
in address between 3GPP devices using Stateless Address 
Autoconfiguration is in the prefix. This means that 3GPP networks 
will already provide a limited form of addressing privacy, and no 
global tracking of a single host is possible through its address. 
On the other hand, since a GGSN/PGW's coverage area is expected to 
be very large when compared to currently deployed default routers 
(no handovers between GGSN/PGWs are possible), a cellular host can 
keep a prefix for a long time. Hence, IPv6 addressing privacy can 
be used for additional privacy during the time the host is on and 
in the same area. The privacy features can also be used to, e.g., 
make different transport sessions appear to come from different IP 
addresses. However, it is not clear that these additional efforts 
confuse potential observers any further, as they could monitor 
only the network prefix part. 


o The use and recommendations of various security services such as 
IPsec or Transport Layer Security (TLS) [RFC5246] in the 
connection of typical applications that also apply to cellular 
hosts are discussed in Section 11 of [RFC6434]. 


Korhonen, et al. Informational [Page 12] 


RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 


o The airtime used by cellular hosts is expensive. In some cases, 
users are billed according to the amount of data they transfer to 
and from their host. It is crucial for both the network and the 
users that the airtime is used correctly and no extra charges are 
applied to users due to misbehaving third parties. The cellular 
links also have a limited capacity, which means that they may not 
necessarily be able to accommodate more traffic than what the user 
selected, such as a multimedia call. Additional traffic might 
interfere with the service level experienced by the user. While 
Quality-of-Service mechanisms mitigate these problems to an 
extent, it is still apparent that DoS aspects may be highlighted 
in the cellular environment. It is possible for existing DoS 
attacks that use, for instance, packet amplification, to be 
substantially more damaging in this environment. How these 
attacks can be protected against is still an area for further 
study. It is also often easy to fill the cellular link and queues 
on both sides with additional or large packets. 


o Within some service provider networks, it is possible to buy a 
prepaid cellular subscription without presenting personal 
identification.  Attackers that wish to remain unidentified could 
leverage this. Note that while the user hasn't been identified, 
the equipment still is; the operators can follow the identity of 
the device and block it from further use. The operators must have 
procedures in place to take notice of third party complaints 
regarding the use of their customers' devices. It may also be 
necessary for the operators to have attack detection tools that 
enable them to efficiently detect attacks launched from the 
cellular hosts. 


o Cellular devices that have local network interfaces (such as WLAN 
or Bluetooth) may be used to launch attacks through them, unless 
the local interfaces are secured in an appropriate manner. 
Therefore, local network interfaces should have access control to 
prevent others from using the cellular host as an intermediary. 


o The 3GPP link model mitigates most of the known IPv6 on-link and 
neighbor cache targeted attacks (see Section 2.2 and Appendix A). 


o Advice for implementations in the face of Neighbor Discovery DoS 
attacks may be useful in some environments [RFC6583]. 


o Section 9 of [RFC6459] further discusses some recent concerns 
related to the security of cellular hosts. 
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Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model 


This appendix aims to very briefly describe the 3GPP IPv6 addressing 
model for 2G (GPRS), 3G (UMTS), and 4G (EPS) cellular networks from 
Release-99 onwards. More information for 2G and 3G can be found in 
3GPP Technical Specifications [TS.23060] and [TS.29061]. The 
equivalent documentation for 4G can be found in 3GPP Technical 
Specifications [TS.23401], [TS.23402], and [TS.29061]. 


There are two possibilities to allocate the address for an IPv6 node: 
stateless and stateful autoconfiguration. The stateful address 
allocation mechanism needs a DHCP server to allocate the address for 
the IPv6 node. On the other hand, the Stateless Address 
Autoconfiguration procedure does not need any external entity 
involved in the address autoconfiguration (apart from the GGSN/PGW). 
At the time of writing this document, the IPv6 Stateless Address 
Autoconfiguration mechanism is still the only mandatory and supported 
address configuration method for the cellular 3GPP link. 


In order to support the standard IPv6 Stateless Address 
Autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW 
shall assign a single /64 IPv6 prefix that is unique within its scope 
to each primary PDP Context or PDN Connection that uses IPv6 
Stateless Address Autoconfiguration. This avoids the necessity to 
perform Duplicate Address Detection (DAD) at the network level for 
any address built by the mobile host. The GGSN/PGW always provides 
an interface identifier to the mobile host. The mobile host uses the 
interface identifier provided by the GGSN/PGW to generate its link- 
local address. The GGSN/PGW provides the cellular host with the 
interface identifier, usually in a random manner. It must ensure the 
uniqueness of such an identifier on the link (i.e., no collisions 
between its own link-local address and the cellular host's). 


In addition, the GGSN/PGW will not use any of the prefixes assigned 
to cellular hosts to generate any of its own addresses. This use of 
the interface identifier, combined with the fact that each PDP 
Context or PDN Connection is allocated a unique prefix, will 
eliminate the need for DAD messages over the air interface and 
consequently reduces inefficient use of radio resources. 
Furthermore, the allocation of a prefix to each PDP Context or PDN 
Connection will allow hosts to implement the Privacy Extensions in 
[RFC4941] without the need for further DAD messages. 


In practice, the GGSN/PGW only needs to route all traffic destined to 
the cellular host that falls under the prefix assigned to it. This 
implies the GGSN/PGW may implement a minimal Neighbor Discovery 
protocol subset since, due to the point-to-point link model and the 
absence of link-layer addressing, the address resolution can be 
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entirely statically configured per PDP Context or PDN Connection, and 
there is no need to defend any addresses other than the link-local 
addresses for very unlikely duplicates. This also has an additional 
effect on a router-to-host NUD. There is really no need for the NUD, 
since from the point of view of GGSN/PGW, GGSN/PGW does not need to 
care for a single address but just routes the whole prefix to the 
cellular host. However, the cellular host must be prepared for the 
unlikely event of receiving a NUD against its link-local address. It 
should be noted that the 3GPP specifications at the time of writing 
this document are silent about what should happen if the router-to- 
host NUD fails. 


See Section 5 of [RFC6459] for further discussion on 3GPP address 
allocation and the 3GPP link model. 


Appendix B. Changes from RFC 3316 


o Clarified that [RFC4941] or similar technologies may be used for 
privacy purposes (as stated in [RFC6459]). 


o Clarified that MLD for link-local addresses is not necessary, but 
doing it causes no harm (instead of saying it may not be needed in 
some cases). 

o Clarified that a cellular host should not do any changes in its 
Stack to meet the 3GPP link restriction on the Router 
Advertisement Prefix Information Options (PIOs). 

o Clarified that a cellular host should not do any changes in its 
Stack to meet the infinite prefix lifetime requirement the 3GPP 


link has. 


o Clarified that the prefix lifetime is tied to the PDP Context/PDN 
Connection lifetime. 


o Clarified explicitly that a NUD from the gateway side to the User 
Equipment's link-local address is possible. 


o Added references to 3GPP specifications. 
o Provided additional clarification on NUD on 3GPP cellular links. 
o Added an explicit note that the prefix on the link is /64. 


o Clarified that DHCPv6 ([RFC3315]) is not used at all for address 
autoconfiguration. 


o Removed all sections that can be directly found in [RFC6434]. 
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o Added 

works 
o Added 
o Added 
o Added 
o Added 
o Added 
o Added 
o Added 
o Added 
o Added 
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clarifications to 3GPP link model and how Neighbor Discovery 
on it. 

[RFC4191] recommendations. 

DHCPv6-based Prefix Delegation recommendations. 

[RFC6106] recommendations. 

reference to [RFC5555] regarding client-based mobility. 

text regarding Router Advertisement MTU option handling. 
Evolved Packet System text. 

clarification on the primary 3GPP IPv6 transition mechanism. 
reference to [RFC5095], which deprecates the RHO. 


references to [RFC5722] and [RFC6980] regarding IPv6 


fragmentation handling. 


o Added 


reference to [RFC6583] for Neighbor Discovery denial-of- 


Service attack considerations. 


o Made the PPP IPV6CP [RFC5072] support text conditional. 
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